Providing customers with a high level of service availability at a low cost is imperative in today's business computing environment. Meeting this goal requires corporations to establish the right availability objectives to meet their business needs, to track the level of availability attained by their application servers, and to take quick corrective action when falling below those objectives. Establishing and achieving the right level of availability is critical. If the service availability is low, there will be a very definite cost in terms of lost revenue as well as in opportunity and customer goodwill costs. If the business is providing a higher level of availability than that required, say striving for 99.99% availability on a 24×7 basis, when the business really only requires 8×5, then the business is incurring a higher cost than necessary in terms of hardware, software, and operations overhead to meet the additional—and unneeded—level of availability. In a very competitive business world it is critical for companies to be able to determine and achieve the right level of availability to meet their business needs, no more and certainly no less.
Yet today many businesses do not have service reliability and availability objectives set in accordance with their business needs, and furthermore they do not have accurate measurements to characterize either their long term (i.e., non-real time) availability or their areas for improvement. Even when objectives are set and reliability data are collected, accurately analyzing and interpreting the results are difficult due to the need for specialized expertise which is often not available. The lack of specialized expertise can lead to improper interpretation of the data, and thus an incorrect estimation of the achieved service availability. If the level of service availability being delivered is incorrectly overestimated, the company's customers can become dissatisfied. If the level of availability is underestimated, the requested improvements, to achieve the desired objective, are unnecessary.
Today, many companies depend on their ticketing systems to determine server availability by looking at the time the system went down and the time the problem was resolved and the system brought back into operation. While ticketing systems can be a rich source of individual failure troubleshooting data, the timing values recorded by the operations staff are often inaccurate, especially when considering the level of accuracy required for these types of measurements (e.g., 99.999% availability is only 5 minutes of downtime a year). The degree of inaccuracy varies from event to event and occurs for many reasons, including unwillingness to document all of the work if the right troubleshooting steps were not taken, and the business of the staff was during the time of the failure, sometimes not closing the ticket for hours or even days after resolution.
For web-facing services, many companies depend on outside tools or services that provide availability monitoring through the network or Internet. These tools and services, which ping a particular application and measure its ability to respond within a specified amount of time, can provide a good measurement of availability from a user's perspective. However they do not provide an accurate measure of availability if their polling rate (i.e., the frequency with which they ping the web servers) is insufficient to measure the desired level of accuracy (e.g., pinging a server every 15 minutes is certainly insufficient for measuring 99.999% availability).
Even in cases where the polling frequency is appropriate, these measurement tools do not provide insight into what portion of the system is at fault when there is a failure or even the frequency of server shutdowns (i.e., the reliability of the servers) making it difficult to troubleshoot problems and improve results. In addition, the tools do not provide insight into the cost of maintaining a given level of availability, that is, into the amount of work required by the operations staff to meet the objectives. For example, when pinging a web-server farm, the tools do not usually know which server is responding behind the load balancing technology in use. The responding server may or may not change between service pings making it very hard to determine individual server behavior.